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DETAILED ACTION 

1 . This action is responsive to the Apphcant's response filed 9/1 5/2005. 

As indicated in Applicant's response, claims 1, 2, 11, 13 have been amended, claim 12 
canceled and claims 16-18 added. Claims 1-9, 1 1, 13-14, and 16-18 are pending in the office 
action. 

Claim Rejections - 35 USC §103 

2. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

3. Claims 1-5, 8-9, 11, 13-14, and 16-18 are rejected under 35 U.S.C. 103(a) asbemg 
unpatentable over Regnell et al., "From Requirements to Design with Use Cases", 3''^ Intl 
Workwhop on Requirements Engineering - Proceeding CAISE '97^ June 1997 (hereinafter 
Regnell), in view of Don Heim, "Requirements Management with Use Cases" Software 
Technology Conference, May 1999 ( hereinafter Heim). 

As per claim 1, Regnell discloses a method for simultaneously developing a family of 
complex systems including a plurality of complex systems ( market, countries, standards - pg. 2, 
ch. 2: Context - Note: complex systems including more than one plurality of such systems based 
on market, country or standard reads on family of plurality of systems)having a common 
software architecture platform, the method comprising: 

forming a requirements object model (ROM) which explains the abstract concepts in 
terms of structured vocabulary (e.g. Fig. 1, pg. 5 - Note: abstract symbols of Tool for 
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representing graphically a use case reads on interaction in terms of abstract concepts from a 
structured vocabulary; Cll, C12 ... C/< Component Model - Fig. 2, pg. 5; MSG, Pseudo code - 
last para, pg. 5); 

developing the use cases based on the set of requirements object model (e.g. Fig. 2, 3, pg. 
5, 6 and related text ) such that the use cases are expressed using the structured vocabulary of the 
requirements object model (e.g. Use Case Model: Textual description of the use cases Ul, U2, U 

-Fig. 1); 

the use cases describing interaction of users with each of the complex systems in terms of 
the structured vocabulary explaining the abstract concepts(e.g. Fig. 3; Use Case Model: textual 
descriptions Ul, U2, U3 -Fig. 1); 

forming functional requirements specification (FRS) which includes use cases (e.g. 
Functionality Specification - Fig. 1, pg. 5 ) 

But Regnell does not explicitly disclose constructing an initial requirement object model 
(ROM), an initial set of use cases, a initial FRS; and forming an amended ROM, forming 
additional use cases based on the amended ROM; changing the FRS simultaneously with the 
additional use cases, repeating formation of additional use cases, amended FRS and ROM until 
desired use cases have been formed and considered; and obtaining a final ROM once all the 
desired use cases have been considered. 

Making iterative adjustment to graphical representation, model representation data (or 
use case scenarios) like those disclosed by Regnell in order to abstracting or implementing the 
functions as required by design/logical model/specifications (or FRS) so to improve the system 
via such mapping and readjustment of said scenarios was a known concept at the time the 
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invention was made because, according to known practice at the time the invention was made, it 
is much preferred to spend resources up front than to ensue rectifying actions and its costly 
consequences when the product is finalized and in use. Accordingly, Regnell discloses how to 
evolve a design from existing stages using evolution and incremental approach via which the 
consolidation of a component specification via a fiinctional distribution model by Regnell using 
fiirther vaUdation and traceability activities as well as multiple incremental projects (see Regnell, 
pg. 6-8; three increments - pg. 9 ch. 5.1; Evolution, Incremental development - pg, 2); and that 
already entails the need for improving as much as possible during the requirements and pre- 
design stage. Because a use case is a symbolic mirror of a set of fiinctional requirement, the 
amending of the requirement object model along with the amendment of use case scenarios from 
Regnell would have been strongly suggested if not implicitly disclosed. The incremental 
improvement to a model and prototype in complex system with of use cases to effect change to a 
requirement model is evidenced in Heim's teachings. Heim, in a method to capture requirements 
for an information system related to a Patient-Record Military Heath System using Use Cases 
analogous to Regnell' s, discloses requirement capture using use cases and incremental changes 
via iteration of scenarios involvmg creating model and use cases until a suitable prototype can be 
tested (e.g. pg. 8), i.e. a change in a use case leading to change to its description using a specific 
structural vocabulary as implemented by the CASE-tool. In case Regnell does not provide 
successive amending of the ROM simultaneously with developing use cases and fiirther 
repeating the cycle ROM change followed by Use Case changes reflecting the changed ROM 
until a fine-tuned ROM is achieved, then it would have been obvious for one of ordinary skill in 
the art at the time the invention was made to implement the ROM by Regnell in light of the 
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incremental approach by Heim, i.e. generating an initial set of FR or use cases, then make 
incremental change to the ROM, use cases and FR, with upgrading ROM, Use cases, and FR in 
response to each increment until a final ROM is achieved. Because each use case represents an 
aspect among more complex business patterns or required functionalities of complex families of 
business logic and making incremental improvement to the requirement model in conjunction 
with new use cases adjustments (changes being imparted to the corresponding description using 
a specific structural vocabulary) the final, one skill in the art would be motivated to do the above 
improvement to Regnell's incremental approach using Heim's teaching because this would 
increase the chance of weeding out imperfection at the requirements stage in the functional 
model approach by Regnell and according to well-known concept of software development, 
alleviate costly drawbacks during later stages of the software lifecycle just as in the traceability 
costs analysis emphasized by Heim or suggested by Regnell. 

As per claim 2, Regnell discloses complex business system and a plurality of developed 
subprojects with coordination of teams aimed as perfecting a model design or models (- pg. 9 ch. 
5.1) and management of the hierarchy of components related to use cases ( e.g. pg. 6-7); hence 
has suggested estabUshment/organization into teams responsible for requirements and design; 
modeling/validating and for constructing scenarios mapping each assigned section of the 
complex system subcomponents or chapters of a master FRS document. 

Official notice is taken that managing a large software project using developing teams 
with overlapping responsibilities ( members of team being used in other teams), from 
requirement analysis, authoring, to design evaluation, implementation, test scenarios and 
verification, change reviews and traceability analysis, was a well-known concept at the time the 
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invention was made. Collaborations between use cases being specified by different authors are 
known in tools like Rational Rose or the likes, thus suggesting overlapping and integrating of 
separately authored Use cases as suggested by Regnell ( see development team -pg. 9 ch. 5.1, 
work parallelization - ch. 5.2, pg. 10) or Heim ( see Heim: pg. 8-14). Hence, in case Regnell 
does not provide overlapping teams for authoring requirement specification and modeling of 
such requirements and for handling specific ones of the chapters, it would have been obvious for 
one of ordinary skill in the art at the time the invention was made to provide teams for modeling 
and for authoring requirements so that members of modeUng ( e.g. object model control team) 
teams cooperate with members of the requirement authoring team as taught by common practice 
as mentioned above. The motivation would be to enable repartition of resource/responsibilities 
and specialization of domain knowledge as well as knowledge sharing; hence facilitate 
supervision and interdependency control and/or concurrent development conflict resolution; all 
of these concepts being integrated in to the common overlapping team concept as mentioned 
above. 

As per claim 3, Regnell does not expressly disclose expressing differences in each 
family of complex system in a component model or plurality of models (see market, countries, 
standards - pg. 2, ch. 2) for each but via projects developed and integrated as from claim 2, the 
establishing of a model for each aspect of a family of complex systems would have been obvious 
because representing one model for a distinct aspect of a family of complex systems would 
enable specific resources to be allotted just to develop and identify the similitude, differences, 
weakness and strengths of what is to be implemented for such distinct member or aspect or 
model, hence increase efficiency, i.e. for the same rationale as mentioned in claim 2. 
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As per claim 4, Regnell discloses initial model ( Fig. 1, 2, 3) as specified in claim 1 but 
does not explicitly disclose constructing one from a team, performing the FRS authoring of use 
cases based upon that initial model and performing fine tuning of the use case and the object 
model 

But it is well evident that when the team, a Umitation being obvious by virtue claims 2-3, 
tackles an aspect of the complex requirement system, the steps of 

constructing an initial requirement object model ( Note: creating a initial object model 
and populating changes herein is inherent to every software engineering and modeling), 

authoring a use case therefor are disclosed as being implicit from the teachings recited in 
claim 1 ( see Regnell: Fig. 1, pg. 5 ; Fig. 2, 3, pg. 5, 6 - Note: It is also noted that the use of Case 
Tool with Use Case for requirement analysis like Rational Rose was a known concept; and 
official notice is taken that authoring in a requirement building process in such tool implicitly 
discloses authoring and creating of model graphical representation; and in light of such Regnell 
has disclosed authoring and building of initial model ); and 

fme tuning of the use cases and refming the model would all have been obvious by virtue 
of claim 1 . 

As per claim 5, Regnell does not expUcitly that authoring of use cases is carried out in 
parallel by respective requirement authoring teams. The concept of parallel developing of 
software and concurrent authoring of model specification by more than one developers in 
frameworks such as Regnell' s using UML or Rationale Rose ( Note: it is not perceivable to have 
a computer tool and many teams to support a complex system development as in Regnell' s when 
every stage has to be done in a non-parallel or non-concurrent fashion) was a known concept in 
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the art of using Unified Modeling Language or CASE Tools which has been designed for such 
concurrent use of users operating from separate and heterogeneous development environments. 
Hence, Regnell in combination with Heim as set forth in claim 1, has disclosed concurrent 
authoring Use Case in parallel of models by development team members. 

As per claims 8 and 9, in conjunction with the rational of claim 3 for getting a model per 
member of a family, one model for a complex system among family of models. Official notice is 
taken that subclass being derived from more general classes, multiplicities of relationships exists 
between classes in an model entity; and that model components be hierarchized by properties or 
attributes according to industrial nature a problem, a domain, a business logic or a system 
behavior, in 00 modeling framework or Case Tools like that of Rational Rose was a well-known 
concept at the time the invention was made. Hence, in view of the teachings by Regnell from 
claim 1 and the rationale in claim 3, the Umitation of expressing the differences between 
members of a family in the requirements model would have been obvious if not implicitly 
disclosed. 

As per claim 11, Official notice is taken that in a software development, the analyzing of 
a requirement model or models to identify shortcomings and effecting corrective actions to 
improve such shortcomings are well-known concepts at the time the invention was made. The 
limitation of claim 1 1 would be implicitly disclosed in Regnell' s ( in combination with Heim's) 
complex software systems development in light of the validation and traceability tracing 
teachings as mentioned in claim 1 . 

As per claim 13, although there is no expUcit disclosing from Regnell or Heim as to 
considering the FRS to be complete when all the use cases are expressed in the structure 
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vocabulary of the final object model, this limitation is implicitly taught in Regnell or Heim's 
requirement fulfilling process ( as per claim 1 1); because if one shortcomings is left unresolved 
in the scheme of requirement vaUdation or verification, the product might not be viable or the 
purpose of the Requirement engineering process as intended by Regnell would be defeated. 

As per claim 14, the Umitation as to develop additional use cases simuhaneously with 
requirement object models or ROMs has been addressed in claim 1 ; the limitation that the 
ROMs is thereby formed would also be disclosed based thereupon. 

As per claim 16, see Regnell (Use Case Model: Textual description of the use cases Ul, 
U2, f/3-Fig. 1) 

As per claim 17, the claim include the subject matter of claim 1 regarding amendment to 
the use cases and simultaneous adjustment to the requirement models; hence is rejected with the 
rationale as set forth in claim 1. 

As per claim 18 ( refer to Regnell: Textual description of the use cases Ul, U2, U3 - 

Fig. 1). 

4. Claims 6 and 7 are rejected under 35 U.S.C. 103(a) as being unpatentable over Regnell et 
al, "From Requirements to Design with Use Cases", 3 Intl Workwhop on Requirements 
Engineering - Proceeding CAISE *97, June 1997; and Heim, "Requirements Management with 
Use Cases" Software Technology Conference, May 1999; as appUed in claim 1, and fiirther in 
view of Langlotz, USPN: 6,366,683 (hereinafter Langlotz). 

As per claim 6, Regnell discloses a complex system while Heim discloses that complex 
systems are medical or hospital related appUcation system (pg. 3-4), In a system using modeling 
language similar to the Case Tool to specify an instance of medical application similar to the 
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suggestion by Heim, Langlotz discloses the medical system is radiology-related and imaging 
system ( Fig. 1-2). Since medical imaging is but one of many medical diagnostic or hospital 
applications, it would have been obvious for one of ordinary skill in the art at the time the 
invention was made to implement one of the business or medical system frameworks as 
suggested by Heim so that a medical imaging or any medical diagnostic appUcation using 
modeling as taught by Langlotz be one of such frameworks, because of the relationships among 
information data as depicted by Langlotz' s medical radiology imaging system would be more 
enhanced for better analysis and reusability when modeling is used. 

As per claim 7, this claim recites the medical imaging limitation of claim 6 in 
conjunction with inter-cooperating teams performing chapters or subsets of the complex FRS as 
addressed in claims 3-5; hence would have been obvious for the same reasons as used in claims 
6, and 3-5 respectively. 

Response to Arguments 
5. Applicant's arguments filed 9/15/05 have been fully considered but they are not 
persuasive. Following are Examiners' remarks. 

(A) Applicant has submitted that Regnell via the Office Action citing Fig. 1 and 2 ( with oval 
and lines between actors and Use cases) does not teach or even suggest providing a requirements 
object model including a structured vocabulary to express use cases and which is designed to be 
amended simultaneously with formation of use cases ( Appl. Rmrks, pg. 12, 2"** para; pg. 13, top 
para). 

First, as to the structured vocabulary to express use cases, the rejection has reasonably 
map such limitation with the textual description of the use cases Ul, U2, U3 from Fig. 1 by 
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Regnell in light of the requirements as shown therein. The claim does not make it very clear as 
to how this structured vocabulary necessarily amounts to in terms of being structured in a 
particular format in order to preclude the use of textual format description as propounded in the 
Office Action as shown above. Applicant's arguments fail to comply with 37 CFR 1. 1 1 1(b) 
because they amount to a general allegation that the claims define a patentable invention without 
specifically pointing out how the language of the claims patentably distinguishes them from the 
references. 

Second, as to the arguments mentioning about 'to be amended simultaneous with . . . 
formation of use cases', following is, in the most part, a repeat of Examiner's observation from 
the previous office action. 

The use of Case tools to produce dynamically a pluraUty of use cases based on the 
perceived set of requirements does not stop at a one time implementing use cases strictly in 
conjunction with a static and unchanging set of requirements. Software change due to change to 
requirement for a plurality of reasons was a integral part of complex systems development; and 
Regnell system is not an exception to being subjected to continual demand for changes, one of 
which due to requirement changes or flaw in the designed system demanding recursive adjust to 
the requirement gathering stage. The rejection has pointed to parts of Regnell where incremental 
adjustments to specifications or use cases are prone to happen; and that Evolution, Incremental 
development (see pg. 2) are part of the Ufecycle of any product, i.e. it would be pointless to 
provide an incremental or evolutionary adjust to a requirement model in a framework just by 
being locked with one static and non-improving requirement-capturing model, which is not what 
is derived from reading Regnell. Heim fiirther has been brought in to evidence via iteration of 
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scenarios. Thus it is understood that in order for incremental and iterative improvement be made 
to obtain a final copy of the requirement model, the steps recited as creating a initial ROM, Use 
case set, FRS and repeating adding of upgraded ROM, Use Cases or FRS, would be perceived as 
being integral to Heim's incremental process. Hence, the combination of Regnell and Heim has 
met the teachings from the claim as interpreted by one skill in the art based on broad and 
reasonable construction of the claim language. Hence, the argument that a change of a model be 
simultaneous with a adjustment in the Use case seemingly is not convincing because a 
requirement model and an use case go hand in hand by the very concept of having a Use case 
tool to represent an aspect of a requirement set ( see B in regard to reference Terry Quatrani as 
below). 

(B) Applicant has submitted that in Regnell' s graphical representations there is no mention of 
amending these representations simultaneous with the formation of use cases (AppL Rmrks, pg. 
13, 3^*^ para) and that Heim does not teach 'formation of amended requirements object models 
which express concepts in terms of structured vocabulary and which are based on use cases 
(Appl. Rmrks, pg. 13, bottom, pg, 14, top para). The rationale to combine Regnell to Heim has 
NOT been purported to overcome structured vocabulary expression of use cases. Applicant fail 
to clearly defeat the grounds of the USC 103(a) rationale -for obviousness— just by asserting a 
alleged lack of a particular feature not being the focal point of said rejection. In response to 
apphcant's arguments against the references individually, one cannot show nonobviousness by 
attacking references individually where the rejections are based on combinations of references. 
See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 
231 USPQ 375 (Fed. Cir. 1986). Section A above has addressed the Applicants concern about 
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the change in structured vocabulary in conjunction with amended use cases and simultaneous 
change to the requirement model in relation to the additional change thereof. Reinforcing the 
well-known concept that UML use cases are made to mirror change in requirements, the action 
again refers to some section in the previously provided reference byTerry Quatrani. In other 
words, the excerpt of Use Cases tool by Terry Quatrani ( Visual Modeling with Rational Rose 
and UML, 1998) shows that changes to any set of requirements, no matter how small, is always 
and immediately mirrored in the Use case view with corresponding changes to the Use case 
instance ( see Quatrani pg. 157-177); and this attests to the otherwise inherent aspect of the 
parallel mapping of use case(s) and requirement specifics during a given iterative development 
stage as mentioned in Heim's ( or Regnell's) modeling tool; that is, a functional requirement 
change needs to be reflected via adjustments to Use case scenario/instance in order to provide an 
incremental and evolutionary form of improvement towards the final set of requirements, i.e. a 
better product release. A rationale for obvious teaching can take into consideration the extent of 
the prior art, the scope/state of useful arts commensurate with the claimed invention, the level of 
one skill in the art at the time the invention was made, and inter alia, the well known concept or 
otherwise inherent teachings based on the above. The parallel adjusting of Use cases and the FR 
model (from which the use cases are instantiated) is deemed integral and virtuall inherent to any 
Use case processing or requirement model framework when such framework is purported to 
consolidate a final model after incremental changes or evolutionary improvements as 
examplified by Regnell or Heim. Besides, the rejection is a combination of two teachings and 
Applicant has failed to show why the rationale to combine as set forth in the rejection has been 
inappropriate. In response to AppUcant picking on each reference taken alone, one cannot show 
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nonobviousness by attacking references individually where the rejections are based on 
combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re 
Merck & Co,, 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). 

For the above reasons, the claims stand rejected as set forth in the Office Action. 

Conclusion 

6. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Tuan A Vu whose telephone number is (272) 272-3735. The 
examiner can normally be reached on 8AM-4:30PM/Mon-Fri, 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Kakali Chaki can be reached on (571)272-3719. 

The fax phone number for the organization where this application or proceeding is 
assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before 
using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571- 
272-3609. 

Any inquiry of a general nature or relating to the status of this application should be 
directed to the TC 2100 Group receptionist: 571-272-2100. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or PubUc PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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